Diagrams are graphical representations of some semantic data. They are used to visualize the data in a way that is understandable to the user and also to allow a more intuitive way to modify/edit the semantic data. An example is a UML class diagram. The data that the class diagram is representing can either be java code that is being directly visualized or a model that the user is using for his design activities. To display different aspects of the java code or model, the user may wish to have multiple diagrams. This means there may be more then one notation element representing the same semantic element, and that the notation data may in fact be stored in a separate file to accomplish this.
This causes a number of problems when the project files that people are working on are under a source control system such as CVS or ClearCase. First take the example of a UML model that contains a state machine where a diagram of that state machine exists in a separately source controlled file. If the user adds a composite state inside the state machine through an external API or a tree control explorer (outside of the diagram), then this will cause the diagram to update to create a view of the new state. If the diagram is under source control it will have a prompt for check-out before the view can be added. This is called a “secondary edit” assuming the “primary edit” is the modification of the UML model that owns the state machine. There can be as many of these “secondary edits” as there are diagrams. This poses two problems: first it is cumbersome for the user to manage these check-out requests, and secondly the user may not have access or permissions to make the check-outs. As well, assuming the secondary edits can be performed, the number of files associated with a given activity has increased considerably making it difficult to isolate where the core change or “primary edit” occurred.
A more damaging problem is when the dynamics of team environment are considered. Specifically this is an issue when two or more people edit the model which in turn spawns secondary edits as above in the same resource. When the contributors go to deliver/check-in their work to source control they could encounter conflicts in a file that they didn't directly change themselves that requires merging either through tool assistance or manual edit of the file. Anytime a merge occurs on a file this is an inherently risky procedure that can cause errors or even file corruption.
Even if one considers cases where a source control system is not utilized there can be issues. Since the secondary edits are causing a file change, this usually implies something additional is being stored inside the file. This consequently will increase the file size of those modified resources. Larger files have impact on loading performance and come at a cost of utilized disk space.
In addition, the semantic data graphically represented by a diagram can be a UML model, business data or simply a set of graphical objects used for drawing pictures. The graphical representation data often needs to be persisted separately from the semantic data. The concept of a notation meta-model to persist the graphical representation data with semantic references has been derived from this need. A notation meta-model is a model designed to represent nodes and arcs in different graphical representations. Usually the semantic information is stored completely separately and merely references to the semantic elements are stored in the notation meta-model. A number of implementations for a notation meta-model exist in the market place most notably the new OMG standard for Diagram Interchange.
There are usually three major concerns when designing notation meta-models:
1. The versatility: how easy is it to create instances of a meta-model and change it dynamically?
2. The extensibility: how easy is it to extend the meta-model and how does this extensibility scale?
3. The manageability: How to manage team interaction? How easy is it to manage change events?
Versatility
A lot of the notation meta-models that exist today fail to recognize the difference between a property that is characteristic of the notational element and one that is use-case driven. For example to represent a shape that is laid out in an x-y layout one needs to have a position and a size constraint in the notational element. However, to represent a shape that is laid out in a vertical flow layout one needs an index constraint. One way to solve this problem is to create a shape notational element that contains both kinds of constraints causing redundancy.
Another way is to create an XY-Shape element and an Order-Shape element. The problem with that shows up when the need to change the layout dynamically presents itself. One then needs to create a new element and destroy the old element after copying the unrelated property values.
Along the same lines exist similar problems if there are notation elements with properties related to their semantic reference. If the semantic element changes dynamically, the old notational element needs to be changed into another that has different properties with the same complication of the recreation.
Extensibility
Usually the designers of the meta-model do not anticipate all the use-cases of their model. That is why it is always a good idea to leave room for extension. The problem here is often the choice of the extensibility mechanism. One way to extend a notation element is to inherit it. Unfortunately, this does not work well if the intent of the extension is to remove properties versus add properties.
Another problem is the scalability of this solution. For example, if there are three notation classes that one needs to add a few properties to, one would then extend every one of them to create three derived classes with the new properties. To add more properties later, one needs to again extend off the leaf classes to create more and more classes. Basically, one either has to live with fewer classes that have redundant properties or live with a huge number of classes that represent all the possible combinations. Both cases are not usually acceptable leave alone feasible.
Another idea, adopted by the DI from OMG, is a property map where both the key and the value are strings. The inherent problem with representing all properties as strings is the inefficiency of serialization and de-serialization. It is also particularly inefficient for reference properties since one loses some inherent traceability features (looking up object inter-references). One also loses the ability to make a complex property that encompasses several other properties (a style).
Manageability
Manageability is a major concern for almost all notation meta-model designers. It deals with how to manage events that are generated when a model change occurs, how to manage merge issues when models get touched by different team contributors and so forth. Usually, some fundamental but not very obvious details make all the difference. For example, the assumption that all notational elements are laid out in relative x-y coordinates proves to be a poor one to make. Consider the case where a shape has sub-shapes that are laid out in a flow layout. The key point to that layout is the order of children. If the meta-model persists x-y constraints relative to the container element for each one of the sub-shapes, it needs to update those constraints when the container is resized. This results in two problems: (i) more events to listen and react to in the client code, and (ii) more deltas to detect and analyze in compare and merge (C&M).
Another problem exists if some modeled properties in the notation meta-model are not team oriented but rather specific to the sole user. Examples of such properties are the diagram zoom ratio or its scroll position. These properties usually hold the user preferences and should not be part of the meta-model but rather in a kind of a local preference store. Impact of changing these properties would be unnecessary deltas for user models, which could lead to complications if these models are under source control in a team environment.